安安～我是ChiYu～
昨天 Playwright 因為按鈕改名而停在 click 以前。看到這個結果，很容易順手得出一個省事的
結論：「Browser Automation 太脆弱，換 WebMCP 就好了。」
有一說一，這個結論下得太快。Playwright 在驗收人類看得見的 UI，WebMCP 則讓目前分頁公開
任務能力；兩者本來就沒有在搶同一份工作。把其中一個失敗拿來替另一個頒獎，多少有點像
螺絲起子不好敲釘子，所以宣布榔頭贏得軟體架構大賽。
我把 Browser Automation、REST API、MCP 與 WebMCP 放進同一個活動搜尋任務，才看清楚
它們真正的差別：誰在呼叫、執行位置在哪裡，以及各自能讀到哪一種狀態。
假設使用者說：「幫我找台北、免費，而且適合入門者的活動。」四種技術都可能出現在流程裡：
search_events。聽起來都在「搜尋活動」，執行位置卻完全不同：
圖 1：四種技術可以出現在同一條任務鏈，但呼叫者、狀態來源與驗證方式不同。
| 技術 | 主要呼叫關係 | 直接看見的狀態 | 適合處理 |
|---|---|---|---|
| Browser Automation | 測試腳本／Agent → 瀏覽器 UI | DOM、accessible name、畫面流程 | E2E、回歸測試、既有網站操作 |
| REST API | HTTP client → server | request、response、授權後資料 | 穩定資料契約與商業行為 |
| MCP | Agent Host／Client ↔ MCP Server | Server 公開的 tools、resources、prompts | 跨網站、桌面或背景能力 |
| WebMCP | 瀏覽器 Agent ↔ 目前網頁 | 分頁內 Tool、route、session 與可見 UI | 使用者正在網站內進行的情境化任務 |
MCP 架構描述的是 Host、Client 與
Server 之間如何協商能力。MCP Server 可以獨立存在，不需要使用者先打開某個網站分頁。
Chrome 的 WebMCP 與 MCP 比較
則把 WebMCP 放在瀏覽器前端。Tool 跟著目前頁面與 route 出現，可以使用該分頁的 session
和可見狀態；離開頁面後，這份能力也應該跟著解除。
所以 WebMCP 最有意思的地方，不是把所有 API 換一個名字，而是讓網站用瀏覽器此刻的情境
描述：「這個頁面現在願意提供哪些任務能力？」
AgentReady Events 的搜尋資料由這支 API 提供：
GET /api/events?location=taipei&price=free&level=beginner
Server 會驗證輸入、查詢活動，再回傳公開摘要。之後加入 WebMCP 時，呼叫鏈會長成這樣：
Agent 選擇 search_events
↓
網站共用 search action
↓
REST API /api/events
↓
server validation 與活動資料
我沒有把查詢規則、授權與資料處理全部搬進 Tool description。這麼做看起來少繞一層，實際上
會在前端複製另一套商業規則。人類表單走一套，Agent Tool 再走一套，兩邊早晚會各自長出
自己的脾氣。
這個專案的判斷很明確：REST API 仍是資料、授權與商業行為的事實來源；WebMCP 負責公開
任務語意，最後呼叫共用 action。Tool 宣告不會替 request 增加權限，也不能取代 server-side
validation。
昨天的 timeout 正好證明 Playwright 還有工作。按鈕能不能被找到、表單能不能用鍵盤操作、
搜尋結果有沒有出現，以及取消 dialog 是否真的擋在最後確認前，這些都屬於人類 UI 契約。
WebMCP 加入後，我反而多了一條交叉檢查線索：
如果把 Playwright 拿掉，只保留 Agent trace，網站很可能變成「Agent 用得動，人類按不下去」。
反過來，只有 UI 測試，也回答不了模型是否從自然語言選對 Tool。兩條路驗收的是不同問題，
不該硬湊成淘汰賽。
之後每碰到一個新能力，我會先問三個問題：
答案通常不會只落在一種技術。完整產品很可能同時保留四層：
MCP：跨系統、背景執行、長期存在的外部能力
WebMCP：目前分頁提供的情境化任務能力
REST API：後端資料、授權與商業規則
Playwright：人類 UI 與整合流程的回歸測試
昨天的按鈕改名屬於 UI 契約，所以由 Playwright 抓到。未來若 Tool schema 少了必要欄位，
問題會落在 WebMCP contract；如果 Agent 已送出正確 input，Server 卻接受過期報名，則要回到
REST API 與商業規則處理。先找對樓層，才不會每次報錯都把整棟房子翻修一遍。
技術位置排好後，還有另一件事不能混在一起：程式存在、Chrome 看見 Tool，以及 Agent 真的
從自然語言呼叫成功，是三種不同強度的證據。
我在系列裡使用 E0～E5 當內部證據標籤。這不是 WebMCP 規範，也不是鐵人賽的評分門檻；
它只是避免我把「程式寫好了」講成「Agent 已經會用了」。
| 讀者看到的狀態 | 內部分級 | 目前能說什麼 |
|---|---|---|
| 目前只是構想 | E0 | 尚未實作或觀察 |
| 程式與契約已存在 | E1 | schema、文件或靜態能力可以查核 |
| 程式與自動測試已通過 | E2 | direct execution 或 deterministic tests 通過 |
| Chrome 已看見網站 Tool | E3 | 真實 browser capability 與 Tool catalog 可觀察 |
| Agent 已從自然語言自行呼叫 | E4 | 保存 prompt、Tool、input、result 與最後回答 |
| 換到乾淨環境仍能重現 | E5 | 同一案例可以被獨立重播 |
今天這份逐步實作有穩定的人類流程與 Playwright 測試，可以主張到 E2；四種技術的責任分工
則是接下來的設計契約。WebMCP Tool 尚未開始實作，所以沒有 E3，更不能提前寫成 E4。
系列開場曾提前看過一份完成版搜尋 trace，那是終點預覽，證據只屬於當時的固定版本與那一題。
它不會倒灌回來，讓今天尚未完成的 Tool 自動升級。
走到今天，活動網站已經能由人類搜尋、收藏、準備報名與取消；固定版本可以重播，Playwright
也把 UI 劇本依賴的畫面線索攤開了。現在至少能分辨：按鈕改名造成 Locator timeout，和未來的
Tool 註冊或 Agent 選擇失敗，不是同一類問題。
這裡就是第一個階段停靠點。WebMCP 此刻仍是待實作、待驗證的方向，下一步才會開始設計
Tool、讓 Chrome 看見 catalog，再觀察 Agent 是否真的選對能力。
不過在寫第一支 Tool 以前，我還缺一份考卷。Agent 偶爾選對一次 search_events，不能順便
替參數、操作順序、人類確認與失敗復原背書。明天我會先列出十種行為、二十道固定題目；
後面每完成一小段，就拿對應題目來撞一次。成功要記，撞歪了也不能偷偷擦掉重考。
iThome鐵人賽
看影片追技術